Skip to content

Fix review comments #550

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
HenrikHL merged 2 commits into from
Sep 10, 2025
Merged

Fix review comments #550

HenrikHL merged 2 commits into from
Sep 10, 2025

Conversation

@HenrikHL
Copy link
Contributor

@HenrikHL HenrikHL commented Sep 10, 2025 •
edited
Loading

  • Removed displayedAddress from condition on OnBehalfOfParties
  • Renamed TransationParty to ActorParty and RecieverParty to make them more specific

PR Type

Enhancement

Description

  • Refactor transaction party schemas for better clarity

  • Split TransactionParty into ActorParty and RecipientParty

  • Update represented party schemas with specific roles

  • Remove outdated displayedAddress documentation references

Diagram Walkthrough

flowchart LR
  A["TransactionParty"] --> B["ActorParty"]
  A --> C["RecipientParty"]
  D["RepresentedParty"] --> E["RepresentedActorParty"]
  D --> F["RepresentedRecipientParty"]
  B --> E
  C --> F
Loading

File Walkthrough
Relevant files
Enhancement
EBL_PINT_v3.0.0.yaml
Refactor party schemas and update references                         

pint/v3/EBL_PINT_v3.0.0.yaml

  • Split TransactionParty into ActorParty and RecipientParty schemas
  • Create separate RepresentedActorParty and RepresentedRecipientParty
    schemas
  • Update schema references in transaction objects
  • Remove displayedAddress condition text from party descriptions
 +85/-9   
EBL_SUR_v3.0.2.yaml
Update surrender API party schemas                                             

ebl/v3/surrender/EBL_SUR_v3.0.2.yaml

  • Replace TransactionParty with ActorParty and RecipientParty
  • Add complete schema definitions for both party types
  • Create separate represented party schemas
  • Update transaction object references
 +83/-8   
Documentation
EBL_ISS_v3.0.2.yaml
Clean up party documentation references                                   

ebl/v3/issuance/EBL_ISS_v3.0.2.yaml

  • Remove displayedAddress condition text from shipper's agent
    description
  • Remove displayedAddress condition text from consignee's agent
    description
 +2/-2     
EBL_v3.0.2.yaml
Clean up party documentation references                                   

ebl/v3/EBL_v3.0.2.yaml

  • Remove displayedAddress condition text from shipper's agent
    description
  • Remove displayedAddress condition text from consignee's agent
    description
 +2/-2     

@qodo-code-review
Copy link

qodo-code-review bot commented Sep 10, 2025

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪
🧪 No relevant tests
🔒 No security concerns identified
⚡ Recommended focus areas for review

Schema Consistency

Verify all references to the removed TransactionParty and RepresentedParty schemas were updated across the entire spec (including examples, request/response bodies, and any external refs). Ensure ActorParty/RecipientParty and RepresentedActorParty/RepresentedRecipientParty are consistently used and required fields align with their usages.

 
        When the transaction recipient is residing on the different platform from the transaction actor's platform, the transaction should be followed by the envelope transfer from the actor's (sending) platform to the recipient's (receiving) platform. If the envelope transfer is caused by either `ENDORSE` `actionCode` or `SACC` `actionCode` transaction (where the recipient is on the different platform), the envelope transfer process is NOT causing transfer of possession of the eBL document, but is merely used as notification for the non-repudiation purposes.
      example: ISSUE
    actor:
      $ref: '#/components/schemas/ActorParty'
    recipient:
      $ref: '#/components/schemas/RecipientParty'
    actionDateTime:
      type: string
      format: date-time
      description: |
        RFC3339 timestamp (UTC) when the transaction was created. Responses MUST be UTC (Z). Precision: milliseconds.
      example: '2024-04-17T07:11:19.531Z'
    reasonCode:
      type: string
      maxLength: 4
      description: |
        A code defined by DCSA indicating the reason for `SURRENDER_FOR_AMENDMENT` (Surrender for Amendment). Possible values are:
        - `SWTP` (Switch to paper)
        - `COD` (Change of destination)
        - `SWI` (Switch BL)

        In case no valid `reasonCode` exists for the `SURRENDER_FOR_AMENDMENT` (Surrender for Amendment) - it is possible to use the `comments` property below to add more information.

        **Condition:** on `actionCode` being `SURRENDER_FOR_AMENDMENT`
      example: SWTP
    comments:
      type: string
      pattern: ^\S(?:.*\S)?$
      description: |
        Free text comment for the party receiving the transaction. In case no valid `reasonCode` exists - this property can also be used to provide a reason.
      maxLength: 255
      example: The B/L has been issued.
  required:
    - actionCode
    - actor
    - actionDateTime

ActorParty:
  type: object
  title: Actor Party
  description: |
    Refers to a company or a legal entity.
  properties:
    partyName:
      type: string
      pattern: ^\S(?:.*\S)?$
      maxLength: 70
      description: |
        Name of the party.
      example: Globeteam
    eblPlatform:
      type: string
      pattern: ^\S+$
      maxLength: 4
      description: |
        The eBL platform of the transaction party. 
        The value **MUST** be one of:
        - `WAVE` (Wave)
        - `CARX` (CargoX)
        - `ESSD` (EssDOCS - This value has been **deprecated**. Please use `IDT`)
        - `IDT` (ICE Digital Trade)
        - `BOLE` (Bolero)
        - `EDOX` (EdoxOnline)
        - `IQAX` (IQAX)
        - `SECR` (Secro)
        - `TRGO` (TradeGO)
        - `ETEU` (eTEU)
        - `TRAC` (Enigio trace:original)
        - `BRIT` (BRITC eBL)
        - `COVA` (Covantis)
        - `ETIT` (e-title)
        - `KTNE` (KTNET)
        - `CRED` (Credore)
        - `BLOC` (BlockPeer Technologies)
      example: BOLE
    identifyingCodes:
      type: array
      minItems: 1
      items:
        $ref: '#/components/schemas/IdentifyingCode'
    taxLegalReferences:
      description: |
        A list of `Tax References` for a `Party`
      type: array
      items:
        $ref: '#/components/schemas/TaxLegalReference'
    representedParty:
      $ref: '#/components/schemas/RepresentedActorParty'
  required:
    - partyName
    - eblPlatform
    - identifyingCodes

RecipientParty:
  type: object
  title: Recipient Party
  description: |
    Refers to a company or a legal entity.
  properties:
    partyName:
      type: string
      pattern: ^\S(?:.*\S)?$
      maxLength: 70
      description: |
        Name of the party.
      example: Globeteam
    eblPlatform:
      type: string
      pattern: ^\S+$
      maxLength: 4
      description: |
        The eBL platform of the transaction party. 
        The value **MUST** be one of:
        - `WAVE` (Wave)
        - `CARX` (CargoX)
        - `ESSD` (EssDOCS - This value has been **deprecated**. Please use `IDT`)
        - `IDT` (ICE Digital Trade)
        - `BOLE` (Bolero)
        - `EDOX` (EdoxOnline)
        - `IQAX` (IQAX)
        - `SECR` (Secro)
        - `TRGO` (TradeGO)
        - `ETEU` (eTEU)
        - `TRAC` (Enigio trace:original)
        - `BRIT` (BRITC eBL)
        - `COVA` (Covantis)
        - `ETIT` (e-title)
        - `KTNE` (KTNET)
        - `CRED` (Credore)
        - `BLOC` (BlockPeer Technologies)
      example: BOLE
    identifyingCodes:
      type: array
      minItems: 1
      items:
        $ref: '#/components/schemas/IdentifyingCode'
    taxLegalReferences:
      description: |
        A list of `Tax References` for a `Party`
      type: array
      items:
        $ref: '#/components/schemas/TaxLegalReference'
    representedParty:
      $ref: '#/components/schemas/RepresentedRecipientParty'
  required:
    - partyName
    - eblPlatform
    - identifyingCodes

RepresentedActorParty:
  type: object
  title: Represented Party
  description: The party on whose behalf the action was performed.
  properties:
    partyName:
      type: string
      pattern: ^\S(?:.*\S)?$
      maxLength: 70
      description: |
        Name of the party.
      example: Globeteam
    identifyingCodes:
      type: array
      items:
        $ref: '#/components/schemas/IdentifyingCode'
  required:
    - partyName

RepresentedRecipientParty:
  type: object
  title: Represented Party
  description: The party on whose behalf the action was directed.
  properties:
    partyName:
Backward Compatibility

Check that API consumers relying on TransactionParty and RepresentedParty can transition smoothly. Confirm no lingering $ref or example payloads use old schema names and that “No Party” guidance under RecipientParty is correctly validated by downstream tooling.

 
    description: |
      An API-Version header **MAY** be added to the request (optional); if added it **MUST** only contain **MAJOR** version. API-Version header **MUST** be aligned with the URI version.
schemas:
  ActorParty:
    type: object
    title: Actor Party
    description: |
      Refers to a company or a legal entity.
    properties:
      eblPlatform:
        type: string
        pattern: ^\S+$
        maxLength: 4
        description: |
          The eBL platform of the transaction party. The value **MUST** be one of:
          - `WAVE` (Wave)
          - `CARX` (CargoX)
          - `ESSD` (EssDOCS - This value has been **deprecated**. Please use `IDT`)
          - `IDT` (ICE Digital Trade)
          - `BOLE` (Bolero)
          - `EDOX` (EdoxOnline)
          - `IQAX` (IQAX)
          - `SECR` (Secro)
          - `TRGO` (TradeGO)
          - `ETEU` (eTEU)
          - `TRAC` (Enigio trace:original)
          - `BRIT` (BRITC eBL)
          - `COVA` (Covantis)
          - `ETIT` (e-title)
          - `KTNE` (KTNET)
          - `CRED` (Credore)
          - `BLOC` (BlockPeer Technologies)
          - `NONE` (To be used as part of the '**No Party**' object when `actionCode` is `SIGN`, `BLANK ENDORSE` or `SURRENDERED`)
        example: BOLE
      partyName:
        type: string
        pattern: ^\S(?:.*\S)?$
        maxLength: 70
        description: |
          Name of the party.
        example: Globeteam
      identifyingCodes:
        type: array
        minItems: 1
        items:
          $ref: '#/components/schemas/IdentifyingCode'
      taxLegalReferences:
        description: |
          A list of `Tax References` for a `Party`
        type: array
        items:
          $ref: '#/components/schemas/TaxLegalReference'
      representedParty:
        $ref: '#/components/schemas/RepresentedActorParty'
    required:
      - partyName
      - eblPlatform
      - identifyingCodes

  RecipientParty:
    type: object
    title: Recipient Party
    description: |
      Refers to a company or a legal entity.

      **Note:** It is possible to use a '**No Party**' placeholder when the `actionCode` is one of the following values: `SIGN`, `BLANK ENDORSE` or `SURRENDERED` (as none of these `actionCodes` require a `recipient`). A '**No Party**' object MUST be populated with the following values:
      ```
        {
          'eblPlatform': 'NONE',
          'partyName': 'NONE',
          'identifyingCodes': [
            {
              'codeListProvider': 'NONE',
              'partyCode': 'NONE',
            }
          ]
        }
      ```
    properties:
      eblPlatform:
        type: string
        pattern: ^\S+$
        maxLength: 4
        description: |
          The eBL platform of the transaction party. The value **MUST** be one of:
          - `WAVE` (Wave)
          - `CARX` (CargoX)
          - `ESSD` (EssDOCS - This value has been **deprecated**. Please use `IDT`)
          - `IDT` (ICE Digital Trade)
          - `BOLE` (Bolero)
          - `EDOX` (EdoxOnline)
          - `IQAX` (IQAX)
          - `SECR` (Secro)
          - `TRGO` (TradeGO)
          - `ETEU` (eTEU)
          - `TRAC` (Enigio trace:original)
          - `BRIT` (BRITC eBL)
          - `COVA` (Covantis)
          - `ETIT` (e-title)
          - `KTNE` (KTNET)
          - `CRED` (Credore)
          - `BLOC` (BlockPeer Technologies)
          - `NONE` (To be used as part of the '**No Party**' object when `actionCode` is `SIGN`, `BLANK ENDORSE` or `SURRENDERED`)
        example: BOLE
      partyName:
        type: string
        pattern: ^\S(?:.*\S)?$
        maxLength: 70
        description: |
          Name of the party.
        example: Globeteam
      identifyingCodes:
        type: array
        minItems: 1
        items:
          $ref: '#/components/schemas/IdentifyingCode'
      taxLegalReferences:
        description: |
          A list of `Tax References` for a `Party`
        type: array
        items:
          $ref: '#/components/schemas/TaxLegalReference'
      representedParty:
        $ref: '#/components/schemas/RepresentedRecipientParty'
    required:
      - partyName
      - eblPlatform
      - identifyingCodes

  RepresentedActorParty:
    type: object
    title: Represented Party
    description: The party on whose behalf the action was performed.
    properties:
      partyName:
        type: string
        pattern: ^\S(?:.*\S)?$
        maxLength: 70
        description: |
          Name of the party.
        example: Globeteam
      identifyingCodes:
        type: array
        items:
          $ref: '#/components/schemas/IdentifyingCode'
    required:
      - partyName

  RepresentedRecipientParty:
    type: object
    title: Represented Party
    description: The party on whose behalf the action was directed.
    properties:
      partyName:
        type: string
        pattern: ^\S(?:.*\S)?$
        maxLength: 70
        description: |
          Name of the party.
        example: Globeteam
      identifyingCodes:
        type: array
        items:
          $ref: '#/components/schemas/IdentifyingCode'
    required:
      - partyName

  EndorsementChainLink:
    type: object
    title: Endorsement Chain Link
    description: |
      Entry in the endorsement chain.
    properties:
      actionDateTime:
        type: string
        format: date-time
        description: Date time when the action occurred.
        example: '2024-09-04T09:41:00Z'
      actionCode:
        type: string
        maxLength: 50
        description: |
          The action performed by the actor. This should be one of:
          - `ISSUE` (The actor issued the document to the recipient, who is the first possessor of the eBL, as designated by the `Issue to Party`)
          - `ENDORSE` (The actor endorsed the document to the recipient)
          - `SIGN` (The actor signed the eBL while it was in the actor's possession)
          - `SURRENDER_FOR_DELIVERY` (The actor requested to surrender the eBL to the recipient for delivery)
          - `SURRENDER_FOR_AMENDMENT` (The actor requested to surrender the eBL to the recipient for amendment)
          - `BLANK_ENDORSE` (The actor endorsed the document in blank)
          - `ENDORSE_TO_ORDER` (The actor endorsed the document to order of the recipient, allowing the recipient to further endorse the eBL to another party)
          - `TRANSFER` (The actor transferred the possession of the eBL to the recipient)
          - `SURRENDERED` (The actor acknowledged that the eBL has been accepted and the lifecycle of the eBL is accomplished)

          Not all actions are applicable to all surrender requests. The combination and order of endorsement chain entries may differ by eBL Solution Provider, based on their rulebook and/or bilateral agreements with carriers.
        example: ISSUE
      actor:
        $ref: '#/components/schemas/ActorParty'
      recipient:
        $ref: '#/components/schemas/RecipientParty'
    required:
      - actionDateTime
      - actionCode
Doc Update Consistency

The removal of displayedAddress references in conditions appears intentional; verify there are no remaining mentions elsewhere and that related validation/rules in other sections remain accurate.

 
  description: |
    The party allowed to act on behalf of the shipper for documentation purposes.

    **Condition:** Either the `address` or a party `identifyingCode` must be provided in the `Shipping Instructions`.
  properties:
    partyName:
      type: string
      pattern: ^\S(?:.*\S)?$
      maxLength: 70
      description: |
        Name of the party.
      example: IKEA Denmark
    address:
      $ref: '#/components/schemas/PartyAddress'
    identifyingCodes:
      type: array
      description: |
        **Condition:** Either the `address` or a party `identifyingCode` must be provided. 
      items:
        $ref: '#/components/schemas/IdentifyingCode'
  required:
    - partyName

Consignee:
  type: object
  title: Consignee
  description: |
    The party to which goods are consigned in the `Master Bill of Lading`.

    **Condition:** Mandatory for non-negotiable BL (`isToOrder=false`)

    **Condition:** If a `displayedAddress` is provided, it must be included in the `Transport Document` instead of the `address`.
  properties:
    partyName:
      type: string
      pattern: ^\S(?:.*\S)?$
      maxLength: 70
      description: |
        Name of the party.
      example: IKEA Denmark
    typeOfPerson:
      type: string
      maxLength: 50
      pattern: ^\S(?:.*\S)?$
      description: |
        Can be one of the following values as per the Union Customs Code art. 5(4):
        - `NATURAL_PERSON` (A person that is an individual living human being)
        - `LEGAL_PERSON` (person (including a human being and public or private organizations) that can perform legal actions, such as own a property, sue and be sued)
        - `ASSOCIATION_OF_PERSONS` (Not a legal person, but recognised under Union or National law as having the capacity to perform legal acts)
      example: 'NATURAL_PERSON'
    address:
      $ref: '#/components/schemas/PartyAddress'
    displayedAddress:
      type: array
      maxItems: 6
      description: |
        The address of the party to be displayed on the `Transport Document`. The displayed address may be used to match the address provided in the `Letter of Credit`.

        **Conditions:** If provided:
          - the displayed address must be included in the `Transport Document`.
          - for physical BL (`isElectronic=false`), it is only allowed to provide max 2 lines of 35 characters. **Note:** Some carriers may choose to allow more lines, please consult the carrier's API documentation to check if this is the case.
          - for electronic BL (`isElectronic=true`), the limit is 6 lines of 35 characters
          - the order of the items in this array **MUST** be preserved as by the provider of the API.
      items:
        type: string
        maxLength: 35
        description: |
          A single address line
        example: Strawinskylaan 4117
    identifyingCodes:
      type: array
      minItems: 1
      items:
        $ref: '#/components/schemas/IdentifyingCode'
    taxLegalReferences:
      description: |
        A list of `Tax References` for a `Party`
      type: array
      items:
        $ref: '#/components/schemas/TaxLegalReference'
    partyContactDetails:
      type: array
      description: |
        A list of contact details
      items:
        $ref: '#/components/schemas/PartyContactDetail'
    reference:
      type: string
      pattern: ^\S(?:.*\S)?$
      maxLength: 35
      description: |
        A reference linked to the `Consignee`.
      example: HHL007
    purchaseOrderReferences:
      type: array
      description: |
        A list of `Purchase Order Reference`s linked to the `Consignee`.
      items:
        type: string
        pattern: ^\S(?:.*\S)?$
        maxLength: 35
        description: |
          A purchase order reference linked to the `Consignee`.
        example: HHL007
  required:
    - partyName
    - identifyingCodes

OnBehalfOfConsignee:
  type: object
  title: On Behalf of Consignee
  description: |
    The party allowed to act on behalf of the consignee for documentation purposes.

    **Condition:** Either the `address` or a party `identifyingCode` must be provided in the `Shipping Instructions`.
  properties:
    partyName:
      type: string

@qodo-code-review
Copy link

qodo-code-review bot commented Sep 10, 2025 •
edited
Loading

PR Code Suggestions ✨

Explore these optional code suggestions:

CategorySuggestion                                                                                                                                    Impact
High-level
Fix "No Party" contradictions

The SUR schemas introduce "No Party" for recipient but keep identifyingCodes

minItems: 1 and omit 'NONE' from RecipientParty while adding it to ActorParty,

which makes the example unvalidatable and misplaces the allowance. Move 'NONE'

to RecipientParty (remove from ActorParty) and add conditional validation (e.g.,

oneOf/if-then) so that when eblPlatform='NONE' the identifyingCodes constraint

is relaxed and partyName='No Party' is permitted. Apply this consistently across

specs to ensure recipients can be "No Party" and actors cannot.

Examples:

ebl/v3/surrender/EBL_SUR_v3.0.2.yaml [148-272] 
    ActorParty:
      type: object
      title: Actor Party
      description: |
        Refers to a company or a legal entity.
      properties:
        eblPlatform:
          type: string
          pattern: ^\S+$
          maxLength: 4

 ... (clipped 115 lines)

Solution Walkthrough:

Before:

# In ebl/v3/surrender/EBL_SUR_v3.0.2.yaml
ActorParty:
  properties:
    eblPlatform:
      description: |
        ...
        - `NONE` (To be used as part of the '**No Party**' object...)
RecipientParty:
  description: |
    **Note:** It is possible to use a '**No Party**' placeholder...
    ```
      { 'eblPlatform': 'NONE', ... }
    ```
  properties:
    eblPlatform:
      # 'NONE' is not a valid value here
    identifyingCodes:
      minItems: 1
  required:
    - identifyingCodes

After:

# In ebl/v3/surrender/EBL_SUR_v3.0.2.yaml
ActorParty:
  properties:
    eblPlatform:
      description: |
        # 'NONE' value and related description are removed.
RecipientParty:
  description: |
    **Note:** It is possible to use a '**No Party**' placeholder...
  properties:
    eblPlatform:
      description: |
        ...
        - `NONE` (To be used as part of the '**No Party**' object...)
  oneOf:
    - required: [partyName, eblPlatform, identifyingCodes]
    - properties:
        eblPlatform: { const: 'NONE' }
        partyName: { const: 'No Party' }
      required: [partyName, eblPlatform]
Suggestion importance[1-10]: 9

__

Why: This suggestion correctly identifies a critical contradiction where the 'No
Party' concept is intended for RecipientParty but the schema changes incorrectly
enable it for ActorParty, making the specification logically inconsistent and
unvalidatable.

High
Possible issue
Remove NONE from actor platforms

Allowing eblPlatform: NONE for ActorParty conflicts with business rules that
only recipients can be "No Party" for those actions. Remove NONE from ActorParty
description to prevent invalid actors and keep "No Party" handling localized to
recipients.

ebl/v3/surrender/EBL_SUR_v3.0.2.yaml [148-177]

 ActorParty:
   type: object
   title: Actor Party
   description: |
     Refers to a company or a legal entity.
   properties:
     eblPlatform:
       type: string
       pattern: ^\S+$
       maxLength: 4
       description: |
         The eBL platform of the transaction party. The value **MUST** be one of:
         - `WAVE` (Wave)
         - `CARX` (CargoX)
         - `ESSD` (EssDOCS - This value has been **deprecated**. Please use `IDT`)
         - `IDT` (ICE Digital Trade)
         - `BOLE` (Bolero)
         - `EDOX` (EdoxOnline)
         - `IQAX` (IQAX)
         - `SECR` (Secro)
         - `TRGO` (TradeGO)
         - `ETEU` (eTEU)
         - `TRAC` (Enigio trace:original)
         - `BRIT` (BRITC eBL)
         - `COVA` (Covantis)
         - `ETIT` (e-title)
         - `KTNE` (KTNET)
         - `CRED` (Credore)
         - `BLOC` (BlockPeer Technologies)
-        - `NONE` (To be used as part of the '**No Party**' object when `actionCode` is `SIGN`, `BLANK ENDORSE` or `SURRENDERED`)
  • Apply / Chat
Suggestion importance[1-10]: 8

__

Why: This suggestion correctly identifies a logical inconsistency where ActorParty should not have NONE as a platform option, as this value is explicitly intended only for RecipientParty under specific conditions, thus preventing invalid data.

Medium
Preserve schema compatibility via composition

Ensure ActorParty and RecipientParty share compatible property shapes with the
prior TransactionParty to avoid breaking clients relying on common fields. Add
an intermediate TransactionParty schema that all transaction references $ref to,
and make ActorParty and RecipientParty extend it using allOf to preserve
backward compatibility.

pint/v3/EBL_PINT_v3.0.0.yaml [955-958]

-actor:
-  $ref: '#/components/schemas/ActorParty'
-recipient:
-  $ref: '#/components/schemas/RecipientParty'
+TransactionParty:
+  allOf:
+    - $ref: '#/components/schemas/BaseTransactionParty'
+ActorParty:
+  allOf:
+    - $ref: '#/components/schemas/BaseTransactionParty'
+RecipientParty:
+  allOf:
+    - $ref: '#/components/schemas/BaseTransactionParty'
+BaseTransactionParty:
+  type: object
+  description: Common transaction party fields
+  properties:
+    partyName:
+      type: string
+      pattern: ^\S(?:.*\S)?$
+      maxLength: 70
+    eblPlatform:
+      type: string
+      pattern: ^\S+$
+      maxLength: 4
+    identifyingCodes:
+      type: array
+      items:
+        $ref: '#/components/schemas/IdentifyingCode'
+    taxLegalReferences:
+      type: array
+      items:
+        $ref: '#/components/schemas/TaxLegalReference'
+  required:
+    - partyName
+    - eblPlatform
+    - identifyingCodes
  • Apply / Chat
Suggestion importance[1-10]: 7

__

Why: The suggestion correctly identifies that replacing TransactionParty with ActorParty and RecipientParty is a breaking change and proposes a valid architectural pattern using a base schema to improve compatibility and maintainability.

Medium
General
Add deprecated alias for renamed schema

Renaming RepresentedParty to RepresentedActorParty and RepresentedRecipientParty
risks reference drift where consumer code expects prior schema names. Add
deprecated aliases that $ref the new schemas to prevent resolution errors in
existing integrations.

pint/v3/EBL_PINT_v3.0.0.yaml [1039-1040]

-representedParty:
-  $ref: '#/components/schemas/RepresentedActorParty'
+RepresentedParty:
+  deprecated: true
+  allOf:
+    - $ref: '#/components/schemas/RepresentedActorParty'
  • Apply / Chat
Suggestion importance[1-10]: 6

__

Why: The suggestion correctly identifies a breaking change from removing RepresentedParty and proposes a good practice of using a deprecated alias to aid backward compatibility, although it oversimplifies by aliasing to only one of the two new schemas.

Low
  • Update

palatsangeetha
palatsangeetha reviewed Sep 10, 2025
View reviewed changes
@HenrikHL HenrikHL merged commit 86057b0 into master Sep 10, 2025
1 check passed
@HenrikHL HenrikHL deleted the Review-comments branch September 10, 2025 15:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@palatsangeetha palatsangeetha palatsangeetha approved these changes

@pedrocarvalhodcsa pedrocarvalhodcsa Awaiting requested review from pedrocarvalhodcsa

Assignees

No one assigned

Labels

Review effort 2/5

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@HenrikHL @palatsangeetha